Connected vehicle lift and storage system

ABSTRACT

A connected vehicle lift and storage system (VLSS) can include a plurality of platforms for storing vehicles that are movable between a plurality of positions. The connected VLSS can communicate with a computing device operated by a user to receive requests to store or retrieve the user&#39;s vehicle(s). As part of the request, location data generated by the computing device can be transmitted to the connected VLSS. In response to the request, the connected VLSS can determine a sequence of platform movements to fulfill the request to store or retrieve the user&#39;s vehicle(s). The sequence can be determined, at least in part, on the location data of the requesting user and/or the location data of other users. In addition, the sequence can be determined to minimize wait times for the requesting user and other users.

CROSS-REFERENCE TO RELATED APPLICATION

This application is a continuation of U.S. patent application Ser. No.15/890,712, filed Feb. 7, 2018, titled “Connected Vehicle Lift AndStorage System”; the aforementioned application being herebyincorporated by reference in its entirety.

BACKGROUND

Vehicle storage systems can be used to store multiple vehicles in alimited amount of real estate. Vehicle storage systems can, for example,store vehicles by stacking the vehicles vertically and thus providingadditional storage for vehicles in a given amount of real estate.

BRIEF DESCRIPTION OF THE DRAWINGS

The disclosure herein is illustrated by way of example, and not by wayof limitation, in the figures of the accompanying drawings in which likereference numerals refer to similar elements, and in which:

FIG. 1 is a block figure diagram illustrating an example vehicle liftand storage system (VLSS) utilizing a multi-axis accelerometer, inaccordance with examples described herein;

FIG. 2A is a block figure diagram illustrating an example connectedVLSS, in accordance with examples described herein;

FIGS. 2B to 2E illustrate front views of an exemplary vehicle lift beingconfigured in accordance with a 3×2 Puzzle VLSS Configuration, inaccordance with examples described herein;

FIG. 3 is a block figure diagram illustrating a network systemimplementing a cloud or network service for managing a plurality vehiclelift and storage systems, in accordance with examples described herein;

FIG. 4 is a flow chart describing an example method of operating anexample vehicle lift and storage system, as shown and described herein;

FIG. 5 is a flow chart illustrating an example method of performing avehicle retrieval operation, as shown and described herein;

FIG. 6 is a flow chart illustrating an example method of performing avehicle storage operation, as shown and described herein;

FIG. 7 is a block diagram illustrating an example user device executingand operating a designated user application for communicating with acloud or network service and/or with a connected VLSS, according toexamples described herein; and

FIG. 8 is a block diagram illustrating a computer system upon whichexamples described herein may be implemented.

DETAILED DESCRIPTION

Examples described herein provide for a vehicle lift and storage system(“VLSS”) that comprise one or more platforms for supporting and/orstoring vehicles. The platforms are movable between a plurality ofpositions to allow vehicles to access the VLSS via one or more vehicularaccess positions. For example, a platform can be moved to a vehicularaccess position of a VLSS and the vehicle can enter the VLSS and ontothe platform via the vehicular access position. Subsequently, theplatform can be moved to another position to store the vehicle in theVLSS. To retrieve the vehicle, the platform supporting the vehicle canbe moved to the vehicular access position and the vehicle can drive offthe platform and out of the VLSS. Depending on the specificimplementation, the platforms can be moved vertically and/orhorizontally. The VLSS can also include one or more moving mechanismsoperatively connected to the platforms for moving the platforms betweenthe plurality of positions. The moving mechanisms can beelectromechanical motors that move the platforms (e.g., vertically,horizontally, or both) via mechanical chain links. The VLSS can beequipped with a control system that controls the moving mechanisms. Incertain implementations, the control system can determine a sequence formoving the platforms such that vehicles can be stored in and retrievedfrom the VLSS. The sequence for moving the platforms can be optimized bythe control system based on a variety of parameters (e.g., user locationdata etc.) to minimize wait times of users in storing and retrievingtheir vehicles from the VLSS.

As contemplated herein, the VLSS can be configured in accordance with aplurality of types of configurations. In a simple example of a VLSS, aplatform of a VLSS is movable between a lower position and an upperposition. When the platform is in the lower position, a vehicle canaccess the platform and drive onto the platform. The platform can thenbe moved to the upper position, which allows at least one additionalvehicle to be stored below the platform. In more complex examples, theVLSS can include a plurality of platforms that are movable between aplurality of positions. In some implementations, the platforms aremovable both vertically and/or horizontally (relative to the ground)between a plurality of positions within the VLSS. For instance, in atype of configuration referred to herein as a “Puzzle VLSS,” platformscan be moved vertically and horizontally to allow for vehicle storageand retrieval operations. In an example 3×2 Puzzle VLSS, five platformsare movable between six positions in the VLSS. The six positions in theVLSS can be arranged in two vertical layers, each having threepositions. The five platforms of the 3×2 Puzzle VLSS can be moved to anyof the six positions and vehicles can access the VLSS by driving onto anopen platform positioned in the lower layer. By arranging the platformsin this manner and enabling them to move vertically and horizontally,vehicles stored on the upper level of the 3×2 Puzzle VLSS can beretrieved without needing to remove any of the vehicles stored on thenon-bottom layers. The 3×2 Puzzle VLSS can also be configured such thatthe top layer of positions within the VLSS are vehicular accesspositions. In a Puzzle VLSS, a platform is typically moved one positionat a time between platform positions. Another type of configuration,referred to herein as a “Tower VLSS,” can comprise a plurality ofplatforms which are movable between a plurality of storage positions andone or more vehicular access positions. In a Tower VLSS configuration,the platforms can be moved directly from a vehicular access position toany of the storage positions within the VLSS. A shaft extending theheight of the Tower VLSS can be used to move platforms (and vehicles)directly from a vehicular access position (e.g., entrance to the TowerVLSS on the ground floor) to any storage position (e.g., a position forplatforms storing vehicles 6 layers above the entrance). One applicationof a Tower VLSS configuration can be a dedicated parking structure. Inthe below discussions, examples may be described with respect to acertain configuration of VLSS (e.g., Tower VLSS, Puzzle VLSS, etc.),such discussions are not intended to be limited to any particular VLSSconfiguration but are rather intended to be generally applicable to anypotential VLSS configuration.

According to embodiments, a network system can provide a cloud ornetwork service for managing one or more aspects of a plurality ofVLSS's. The network system can be connectively coupled to the VLSS's viaone or more networks (e.g., the Internet). And the plurality of VLSS'scan be geographically dispersed (e.g., located at various locations). Ata high level, the network system can communicate with the VLSS's to, forexample, identify users, assign spaces for users' vehicles, communicatewith users regarding updates or service details, process payments, andmanage the maintenance and operation of the VLSS's. The network systemcan maintain user profiles to enable users to have a consistent andseamless experience across all the VLSS's managed by the serviceplatform. A user profile can store information regarding or related tothe corresponding user, including, for example, payment information,vehicle information, usage history, permanent space allocation(s) atparticular VLSS's (if any), etc. For instance, a user can utilize asingle form of identification (e.g., a wireless key fob, a contactlesscard, a computing device executing a user application, etc.) to accessand reserve spaces at several (or all) of the VLSS's managed by thecloud or network service.

According to embodiments, the network system can further maintaindynamically-updated availability information for each of the pluralityof VLSS's it manages. By maintaining such availability information, thenetwork system can dynamically assign or allocate spaces for users atany of the plurality of VLSS's in response to user requests to storevehicles at various locations. According to certain implementations, theavailability information can simply indicate, for each VLSS, a number ofopen (e.g., unassigned and/or unreserved, etc.) spaces available forstoring vehicles. In other implementations, the availability informationcan include additional more detailed information such as maintenanceinformation, user information, etc.

In various examples, a VLSS can include a plurality of sensors. Theoutput of the sensors can be used by the control system to generatecontrol signals to control the moving mechanisms. For example, thesensors can detect that a platform has moved in place into a positionallocated by the control system (e.g., in accordance with the sequencedetermined by the control system). In response, the control system canhalt operations of the moving mechanisms for the platform. In addition,the sensors can detect for safety events such as a moving platformmaking unexpected contact with, for example, an open car door. Inresponse, the control system can cause the platform to stop moving andreturn to its original/starting position to avoid damage to theplatform, the vehicle on the platform, and the object the platform camein contact with. Furthermore, the sensors can detect if a component ofthe VLSS is malfunctioning (e.g., electromechanical motor, mechanicalchain link, etc.).

According to embodiments, the sensors utilized by the VLSS can includeaccelerometers placed on the platforms. Each platform of the VLSS caninclude an accelerometer and the control system can receive theaccelerometer output to generate control signals and/or safety signalsto control the moving mechanisms in moving the platforms. Theaccelerometer can be a multi-axis accelerometer that is able to detectthe pitch, roll, and yaw of the platform on which it is placed. Theaccelerometer output can further indicate that the platform has madeimpact with the frame of the VLSS or the ground (e.g., as the platformmoves into the desired position) or with another object (e.g., an opendoor with another vehicle). In certain implementations, a singleaccelerometer can be used for a given platform of the VLSS, replacing aplurality of other sensors that would have been used for the samepurposes (e.g., detecting platform impact and safety events). Thus,among other benefits, the use of a multi-axis accelerometer decreasesthe complexity and costs of building the VLSS by reducing the number ofsensors required to ensure safe operations in moving the platforms ofthe VLSS.

In various implementations, the control system can monitor the output ofan accelerometer of a given platform to detect for safety eventsassociated with the given platform. Examples of safety events that canbe detected by the control system based on the accelerometer outputinclude the platform (or the vehicle on the platform) making undesiredor unexpected contact with another object while the platform is beingmoved, a failure of a moving mechanism or a mechanical link, or aunexpected movement of the platform while the platform being maintainedin place. As one example, a safety event can be detected based on themonitored output from the accelerometer indicating that a pitchrotation, a roll rotation, and/or a yaw rotation of the platform isabove a certain threshold value. Such an output from the accelerometercan indicate an impact while the platform is being moved such that theplatform experiences a rotation or tilt. As one example, the door of avehicle being stored on the platform may be ajar or open. As theplatform is being lowered, for example, the vehicle's door may makecontact with another platform or another vehicle being stored in theVLSS, causing the moving platform to experience a rotation or tilt. Asanother example, while being lowered or raised, the platform can impactan object on one side, also causing the moving platform to experience arotation or tilt. In response to detecting of such safety events, thecontrol system can be configured to generate a safety signal to causethe moving mechanism to cease attempting to bring the platform to fromits initial position to the desired position to prevent damage to theplatform, the vehicle on the platform (e.g., to prevent the platformfrom tilting such that the vehicle falls off the platform), and theobject with which impact is made (e.g., another platform or anothervehicle). In some examples, the moving mechanism can further, inresponse to the safety event signal, move the platform back to itsinitial position (or to another safe position). Furthermore, the outputfrom the accelerometer that indicate a pitch, roll, or yaw of theplatform exceeding a threshold value can indicate that one or moremechanical links of the platform have failed. The control system candetect such a safety event and, in response, take corrective actions.

As used herein, a computing device refers to devices corresponding todesktop computers, cellular devices or smartphones, personal digitalassistants (PDAs), laptop computers, virtual reality (VR) or augmentedreality (AR) headsets, tablet devices, television (IP Television), etc.,that can provide network connectivity and processing resources forcommunicating with the system over a network. A computing device canalso correspond to custom hardware, in-vehicle devices, or on-boardcomputers, etc. The computing device can also operate a designatedapplication configured to communicate with the network service.

One or more examples described herein provide that methods, techniques,and actions performed by a computing device are performedprogrammatically, or as a computer-implemented method. Programmatically,as used herein, means through the use of code or computer-executableinstructions. These instructions can be stored in one or more memoryresources of the computing device. A programmatically performed step mayor may not be automatic.

One or more examples described herein can be implemented usingprogrammatic modules, engines, or components. A programmatic module,engine, or component can include a program, a sub-routine, a portion ofa program, or a software component or a hardware component capable ofperforming one or more stated tasks or functions. As used herein, amodule or component can exist on a hardware component independently ofother modules or components. Alternatively, a module or component can bea shared element or process of other modules, programs or machines.

Some examples described herein can generally require the use ofcomputing devices, including processing and memory resources. Forexample, one or more examples described herein may be implemented, inwhole or in part, on computing devices such as servers, desktopcomputers, cellular or smartphones, personal digital assistants (e.g.,PDAs), laptop computers, VR or AR devices, printers, digital pictureframes, network equipment (e.g., routers) and tablet devices. Memory,processing, and network resources may all be used in connection with theestablishment, use, or performance of any example described herein(including with the performance of any method or with the implementationof any system).

Furthermore, one or more examples described herein may be implementedthrough the use of instructions that are executable by one or moreprocessors. These instructions may be carried on a computer-readablemedium. Machines shown or described with figures below provide examplesof processing resources and computer-readable mediums on whichinstructions for implementing examples disclosed herein can be carriedand/or executed. In particular, the numerous machines shown withexamples of the invention include processors and various forms of memoryfor holding data and instructions. Examples of computer-readable mediumsinclude permanent memory storage devices, such as hard drives onpersonal computers or servers. Other examples of computer storagemediums include portable storage units, such as CD or DVD units, flashmemory (such as carried on smartphones, multifunctional devices ortablets), and magnetic memory. Computers, terminals, network enableddevices (e.g., mobile devices, such as cell phones) are all examples ofmachines and devices that utilize processors, memory, and instructionsstored on computer-readable mediums. Additionally, examples may beimplemented in the form of computer-programs, or a computer usablecarrier medium capable of carrying such a program.

System Descriptions

FIG. 1 is a block figure diagram illustrating an example vehicle liftand storage system (VLSS) utilizing a multi-axis accelerometer, inaccordance with examples described herein. As illustrated, the VLSS 100can be a Puzzle VLSS that includes a plurality of platforms that can bemoved both horizontally and vertically to allow for vehicle storage andretrieval. As FIG. 1 illustrates a sideways view of the VLSS 100, onlyvertical movements of its platform(s) are illustrated. Alternatively,VLSS 100 can also be a simple two-level vehicle lift in which theplatforms move vertically.

According to embodiments, the VLSS 100 can include a platform 120 forsupporting a vehicle 190. The platform 120 can be moved verticallythrough a range of movement 121 between a raised position 122 and alowered position 123. In certain examples, the platform 120 may also bemoved horizontally (not shown in FIG. 1) while in either the raisedposition 122 or the lowered position 123. The VLSS further includes acontrol system 145 that controls a motor mechanism 150 to move theplatform 120 between the raised position 122 and the lowered position.The platform 120 is operatively coupled to the motor mechanism 150 via amechanical link 155. The motor mechanism 150 can be an electromechanicalmotor and the mechanical link 155 can be a chain link. The vehicle 190may be driven onto the platform 120 while the platform 120 is in thelowered position 123. The platform 120 can be raised to the raisedposition 122 to allow an additional vehicle to be stored underneath theplatform 120.

To operate the VLSS 100, a user may interact with the VLSS 100 via auser terminal 110. The user terminal 110 can be a computing device(e.g., a touchscreen computer, a tablet computer, etc.) presenting auser interface which enables the user to initiate vehicle storage orvehicle retrieval operations. For example, to store the vehicle 190 onthe VLSS 100, the user can, after driving vehicle 190 onto the platform120 while it is in the lowered position 123, interact with the userterminal 110 to instruct the VLSS 100 to store the vehicle 190, whichmay include moving the platform 120 to the raised position 122.Similarly, to retrieve the vehicle 190, the user can interact with theuser terminal 110 to instruct the VLSS 100 to lower the platform 120 ifit is in the raised position 122 such that the vehicle 190 can be drivenoff the platform 120. In certain examples, such as in a Puzzle VLSSconfiguration having a plurality of platforms, the user can provideidentification and/or authentication information (e.g., a user ID, anauthorization code, etc.) via the user interface to enable the VLSS 100to identify the platform 120 that stores the user's vehicle 190 in ordermove the appropriate platform 120 to the lowered position 123 such thatthe vehicle 190 can be retrieved from the VLSS 100. As an alternative orin addition, the user may utilize a wireless key fob to interact withthe user terminal 110 and/or the VLSS 100 to store and retrieve thevehicle 190. Furthermore, the VLSS 100 may allow user interactions via auser application executed on a computing device operated by the user(e.g., a smartphone, a smartwatch, a tablet computer, etc.). Forexample, via the user application, the user can instruct the VLSS 100 tostore or retrieve vehicle 190. The VLSS 100 may communicate with thecomputing device via one or more networks 180 such as the Internet orone or more local network connections (e.g., a local or peer-to-peerWi-Fi connection, Bluetooth, etc.).

According to embodiments, the user terminal 110 can transmit user input111 to the control system 145. The user input 111 can identify the userand the requested operation (e.g., vehicle storage or vehicleretrieval). For a requested vehicle storage operation, the user input111 can further identify the platform (e.g., platform 120) on which thevehicle 190 of the user is located. In response, the control system 145can associate the identified platform with the user such that theappropriate platform can be identified when the user requests retrievalof his or her vehicle 190. As an alternative, the control system 145 canautomatically associate a platform with a user during a vehicle storageoperation based on sensor outputs (e.g., output from an accelerometer135 attached to the platform 120). For example, the control system 145can determine, based on the sensor output, that a vehicle has beendriven onto platform 120. In response, the control system 145 canautomatically associate the platform 120 with the next vehicle storageoperation request. In contrast, for a requested vehicle retrievaloperation, in response to user input 111, the control system 145 canidentify the platform associated with the user (e.g., platform storingthe user's vehicle 190) and determine a sequence of platform movementsto allow the user to retrieve his or her vehicle 190. For instance, thecontrol system 145 can determine a sequence of platform movements tomove the platform 120 that stores the user's vehicle 190 to the loweredposition 123 such that the user can retrieve vehicle 190.

Various sensors can be utilized to enable the control system 145 toproperly control the motor mechanism 150 in moving the platform 120between the raised position 122 and the lowered position 123. Forinstance, based on the sensors' output, the control system 145 cangenerate a control signal 146 to control the motor mechanism 150 inmoving the platform 120. The control system 145 can detect potentialsafety issues associated with the platform 120 based on the sensors'output and can generate a safety signal 147 in response. According toembodiments, the sensors can include an accelerometer 135 attached tothe platform 120. In one example, the accelerometer 135 is attachedunderneath the platform 120 and located at the midpoint of the bottomsurface of the platform 120. In other examples, the accelerometer 135can be located elsewhere on the platform 120. The accelerometer 135 canbe a multi-axis accelerometer that can detect the movement, impact, andorientation of the platform 120. For instance, the accelerometer 135 candetect the pitch, roll, and yaw of the platform 120. The accelerometer135 can also detect an impact experienced by the platform 120 (e.g.,another object impacting the platform 120, the platform 120 impactinganother object as it moves from one position to another, the vehicle 190impacting another object as the platform moves from one position toanother etc.).

In some examples, the accelerometer 135 can be a wireless,battery-operated sensor device. The accelerometer 135 can communicatewith the control system 145 via a wireless gateway 125 of the controlsystem 145 over a wireless sensor link 140. The accelerometer 135 cantransmit, over the wireless sensor link 140, various data related to theplatform 120 to the control system 145. The data can include a pitchrotation 136 of the platform 120, a roll rotation 137 of the platform, ayaw rotation 138 of the platform 120, and an indication of an impact 139experienced by the platform 120. The accelerometer 135 can be configuredto operate in a manner to prolong or maximize its battery life. Forinstance, the accelerometer 135 can be configured to transmit data overthe wireless sensor link 140 only when movement is detected by theaccelerometer 135. In addition, while the platform 120 is stationary,the accelerometer 135 can enter a standby mode and/or temporarilydisable the wireless sensor link 140 to conserve energy usage.

In various aspects, the controls system 145 can generate a controlsignal 146 to control the motor mechanism 150 operations in moving theplatform 120 (e.g., via the mechanical link 155). As an example, thecontrol system 145 can, in response to the user input 111 or anothersignal indicating a request for vehicle retrieval or storage operations,determine to move platform 120 from the raised position 122 to thelowered position 123. Based on this determination, the control system145 can generate a corresponding control signal 146. In certainimplementations, the control signal 146 can cause the motor mechanism150 to move the platform 120 a predetermined distance from its initialposition (e.g., the raised position 122) to a desired position (e.g.,the lowered position 123). For instance, the control signal 146 cancause the motor mechanism 150 to operate a calibrated number ofrevolutions to cause the platform 120 to move from the raised position122 to the lowered position 122. The control system 145 can look up, ina database or a memory storage element, the calibrated number ofrevolutions needed to move the platform 120 from the raised position 122to the lowered position 123. The control system 145 can then generatethe control signal 146 to cause the motor mechanism 150 to operate thecalibrated number of revolutions (e.g., as measured by the revolutioncounter 160) in order to move the platform 120 from the raised position122 to the lowered position 123.

In certain implementations, the motor mechanism 150 and/or themechanical link 155 can be coupled to an instrument for measuring orestimating the amount of distance the platform 120 has traveled whilebeing moved into the desired position. In one variation, such aninstrument can be a revolution counter 160 for counting the number ofrevolutions by the motor mechanism 150 or a gear attached to themechanical link 155.

In an example, the calibrated number of revolutions can be determinedbased on calibrations performed by an administrator or an engineer foreach possible platform movement. For a VLSS having three verticallayers, for example, separate calibrations can be performed for movingthe platform 120 between a top position to a middle position and formoving the platform 120 between the middle position to a bottomposition. In addition, the calibrations can be periodically performed tocompensate for changes in the components of the motor mechanism 150and/or the mechanical link 155 over time. For instance, the mechanicallink 155 can be a chain link that can stretch over time, which canaffect the distance the platform 120 is moved given the same number ofrevolutions performed by the motor mechanism 150. Accordingly, byperiodically performing calibrations, the performance of the VLSS 100can be guaranteed. In some examples, the VLSS 100 can be configured toself-calibrate based on data transmitted from the accelerometer 135 via,for example, the wireless sensor link 140. To perform self-calibrations,the control system 145 can receive, from the accelerometer 135,indications of impact (e.g., impact 139) by the platform 120 as it movesinto the desired position and compare this data with the revolutioncounter 160 configured to measure or estimate the number of revolutionsby the motor mechanism 150 and/or a gear coupled to the mechanical link155. If the mechanical link 155 has been stretched over time, theaccelerometer 135 may indicate impact by the platform 120 as it movesinto the desired position prior to the revolution counter 160 reachingthe calibrated number of revolutions. In response, the control system145 can self-calibrate by correspondingly adjusting (e.g., lowering) thecalibrated number of revolutions for moving the platform 120 from theinitial position to the desired position.

According to embodiments, the control system 145 can monitor data (e.g.,pitch 136, roll 137, yaw 138, impact 139) transmitted by theaccelerometer 135 to generate the safety signal 147 which can bereceived by the motor mechanism 150. The safety signal 147 can be asignal generated in response to a detected safety event. In certainimplementations, the control signal 146 and safety signal 147 can begenerated and treated by the control system 145 and the motor mechanism150 as a single signal. A safety event can correspond to the platform120 making unexpected impact with another object. The safety event canalso correspond to the motor mechanism 150 or the mechanical link 155experiencing issues or failing while the platform 120 is being move tothe lowered position 123. For instance, one or more mechanical chainlinks constituting the mechanical link 155 can snap or break, or themotor mechanism 150 can jam. The safety event can further correspond toexternal events such as a seismic event (e.g., earthquake) or accidentsuch as a vehicle, while being driven, crashing into the lift frame 115.In each of these cases, the accelerometer 135 can detect the effects onthe platform 120 and, in response, the control system 145 can generatean appropriate safety signal 147.

As an example, the control system 145 can, in response to user input111, generate the control signal 146 to cause the motor mechanism 150 tomove the platform 120 from the raised position 122 to the loweredposition 123. As the platform 120 begin to move, the accelerometer 135can automatically begin transmitting data (e.g., pitch 136, roll 137,yaw 138, impact 139) over the wireless sensor link 140 to the controlsystem 145. In one scenario, the platform 120 can impact an object priorto reaching the lowered position 123, thereby causing a safety event. Insuch a scenario, the control system 145 can determine the occurrence ofa safety event by analyzing the data from the accelerometer 135 withreference to the revolution counter 160. For instance, data from theaccelerometer 135 (e.g., impact 139) can indicate the impact with theobject before the revolution counter 160 having reached the calibratednumber of revolutions needed to bring the platform 120 from the raisedposition 122 to the lowered position 123. Based on this analysis, thecontrol system 145 can determine that the data from the accelerometer135 indicates an undesired and/or unexpected impact by the platform 120(e.g., an impact other than the one experienced by the platform as itmoves into position into the lowered position 123), and thus indicates asafety event.

In addition, the control system 145 can determine a safety event hasoccurred in response to the accelerometer 135 detecting that theplatform 120 experiences a pitch rotation, roll rotation, or a yawrotation. For instance, when the platform 120 impacts an object as itmoves from its initial position to a desired position, the platform 120can experience a rotation or tilt. The accelerometer 135 can detect sucha rotation experienced by the platform 120 force and communicate to thecontrol system such a detection via measurements such as the pitch 136,roll 137, or yaw 138. The control system 145 can, in response toreceiving data from the accelerometer 135 that exceeds one or morethresholds, determine that a safety event has occurred and can generatea safety signal 147. For instance, in the example given, the platform120 can impact as it moves down from the raised position 122 to thelowered position 123. As it makes impact, the platform 120 canexperience a tilt to one side due to the impact with the object (e.g.,because the object is located on one side of the platform 120). Theaccelerometer 135 can transmit data (e.g., pitch 136, roll 137, and/oryaw 138) that indicate the tilt of the platform 120 to the controlsystem 145 via the wireless sensor link 140. In response to receivingfrom the accelerometer 135 that exceed predetermined thresholds (e.g.,pitch 136 exceeding a pitch rotation threshold value, or roll 137exceeding a roll rotation exceeding a roll rotation threshold value,and/or yaw 138 exceeding a yaw rotation threshold value), the controlsystem 145 can determine that a safety event has occurred and generatean appropriate safety signal 147.

According to embodiments, the control system 145 can further determinethe occurrence of a safety event based on data from the accelerometer135 when the platform 120 is not moving from one position to another.For example, the mechanical link 155 can fail while the platform 120 isstationary or the VLSS 100 can experience a seismic event or an accident(e.g., the lift frame 115 can be hit by a vehicle etc.). In theseinstances, the accelerometer 135 can detect movement of the platform 120caused by the safety event and transmit the data generated to thecontrol system 145 via the wireless sensor link 130. The control system145 can, in response, detect the occurrence of the safety event based onreceiving the accelerometer data while the platform 120 is supposed toremain in place.

In various aspects, in addition to detecting the occurrence of a safetyevent, the control system 145 can further discern a type of safety eventby analyzing the data from the accelerometer 135 and other sensors. Forinstance, the control system 145 can further determine that a detectedsafety event corresponds to a failure of the mechanical link 155. Thecontrol system 145 can also determine that another detected safety eventcorresponds to an impact against an external object while the platform120 is being moved into a desired position. In addition, based on thedata from the accelerometer 135 (e.g., pitch 136, roll 137, yaw 138),the control system 145 can determine which side of the platform impactedthe external object while it is being moved into the desired position.At a high level, because the sensor readings corresponding to each ofthe types of safety events differ by nature, the control system 145 candetermine which safety event type a detected safety event most likely isby analyzing the received sensor data, including data from theaccelerometer 135. Thus, to determine safety event types, the controlsystem 145 can maintain event profiles for a plurality of types ofsafety event types. An event profile can comprise simulated oraccumulated sensor data that correspond to a particular type of safetyevent. For instance, impact with an external object on one side of theplatform 120 as it is being moved into a position can have a differentevent profile compared to impact with an external object on another sideof the platform 120. A failure of the mechanical link 155 can also haveone or more safety event profiles. Separate safety event profiles caneven be maintained for failures of different components of themechanical link 155. For instance, the mechanical link 155 can comprisemultiple chain links (e.g., one on each corner of the platform 120) andindividual safety event profiles can be maintained for failure of eachof the multiple chain links. The control system 145 can analyze thereceived data from the accelerometer 135 and other sensors and comparethe received data against the event profiles to determine an eventprofile that best matches the received sensor data to determine a typeof safety event that corresponds to the received sensor data. Inaddition to or as an alternative, a machine-learned model (e.g.,tree-based model, an artificial neural network, etc.) can be utilized todetermine a safety event type based on sensor data (e.g., data from theaccelerometer 135). The machine-learned model can be trained over timevia supervising input from an administrator or lift operator. Thecontrol system 145 can further utilize other information, such as thestate of the platform 120 (e.g., whether the platform 120 was beingmoved from one position to another while the safety event was detected),to aid in determining a safety event type.

According to examples, the safety signal 147 generated by the controlsystem 145 can cause the VLSS 100 to perform one or more operations toprotect the vehicle(s) and components of the VLSS 100 affected by thedetected safety event. For instance, if the detected safety eventcorresponds to the platform 120 impacting an external object as theplatform 120 is being moved from its initial position to a desiredposition (e.g., while the motor mechanism 150 is operating in a normalmode of operation), the safety signal 147 can cause the motor mechanism150 to stop moving the platform 120 in the direction of the desiredposition (e.g., to stop operating in the normal mode of operation). Inaddition, the safety signal 147 can cause the motor mechanism 150 toperform safety operations (e.g., enter a safety mode) including movingthe platform 120 back to its initial position or to another positionthat is deemed safe by the control system 145 (e.g., a position betweenthe initial position and the desired position). In other instances, suchas when the detected safety event corresponds to a seismic event or to afailure of the mechanical link 155, the safety signal 147 can cause oneor more safety latches to engage to improve the stability of theplatform 120. In certain implementations, the safety signal 147 can bebased on various sensor data such as data received from theaccelerometer 135. For instance, if the data from the accelerometer 135(e.g., pitch 136, roll 137, yaw 138) indicate that the platform 120 isexperiencing a tilt in a particular direction due to the detected safetyevent, the control system 145 can generate the safety signal 147 tocause the motor mechanism 150 to counteract or offset the detected tiltcaused by the safety event. In certain implementations, the safetysignal 147 can be generated based on the type of safety event determinedby the control system 145.

According to embodiments, the control system 145 can generate an alertmessage 148 for transmission over one or more networks 180 to anadministrator system 195. The alert message 148 can be transmitted via anetwork interface 170 of the VLSS 100. In addition or as an alternative,the alert message 148 can be transmitted to a cloud or network servicefor managing the VLSS 100. The alert message 148 allows an administratoror operator overseeing the operations of the VLSS 100 to be notified ofevents that require their attention. For instance, the alert message 148can be generated for transmission to the administrator system 195 inresponse to detecting a safety event. The alert message 148 can includedetailed information regarding the detected safety event including, forexample, time of the detected safety event, type of safety eventdetected, identification of the affected platform(s), identification ofvehicles and/or users affected, and the like. In certainimplementations, the VLSS 100 can be equipped with one or more camerasand the alert message 148 can include a video clip or a link to a videoclip of the detected safety event.

Furthermore, the control system 145 can generate the alert message 148regarding the maintenance and upkeep of the VLSS 100. For example, therevolution counter 160 can indicate a cumulative revolution exceeding amaintenance threshold, which may indicate a recommended or requiredservice of the motor mechanism 150 and/or the mechanical link 155. Inresponse, control system 145 can generate an alert message 148 fortransmission to the administrator system 195 that indicates detailedinformation regarding the recommended or required service, including,for example, identification of the motor mechanism(s) 150 and/ormechanical link(s) 155 requiring service and type of service that isrecommend or required. In this manner, the VLSS 100 can dynamicallyalert administrators or operators of the VLSS 100 when maintenance orservice is required by individual components of the VLSS 100. Becausefrequency of desired maintenance and service can depend on the usage ofthe VLSS 100, it is particularly advantageous for the VLSS 100 to beable to dynamically alert the administrator or operator when maintenanceor service is required for particular components of the VLSS 100.

FIG. 2A is a block figure diagram illustrating an example connectedvehicle lift and storage system, in accordance with examples describedherein. The connected VLSS 200 comprises a control system 210 and avehicle lift 250. The connected VLSS 200 can further include componentsillustrated and described with respect to FIG. 1 including, for example,one or more motor platforms, mechanisms, mechanical links, etc.

According to embodiments, the vehicle lift 250 can store a plurality ofvehicles and can comprise a plurality of platforms (not illustrated inFIG. 2) that can be moved between a plurality of positions. The vehiclelift 250 can have multiple levels and the platforms can be movedvertically between them. In certain examples, the platforms can also bemoved horizontally between a plurality of horizontal positions. Thevehicle lift 250 can be configured in accordance with a plurality ofpossible configurations. For instance, the vehicle lift 250 can be asimple vehicle lift in which the platforms of the vehicle lift can bemoved only vertically. The vehicle lift 250 can also be of a Puzzle VLSSconfiguration in which the platforms can be moved vertically andhorizontally. In addition, the vehicle lift 250 can be of a Tower VLSSconfiguration. In each possible configuration, vehicles can enter andexit the vehicle lift 250 via one or more vehicular access positions. Aplatform can be moved into a vehicular access position to enable avehicle to enter the vehicle lift 250 and onto the platform.Subsequently, the platform can be moved to another position within thevehicle lift 250 to store the vehicle. When the vehicle is to beretrieved, the platform can be moved back to the vehicular accessposition (or to another vehicular access position) so that the vehiclecan be driven off the platform by the user. The platforms can be movedby motor mechanisms and mechanical links similar to those described withrespect to FIG. 1 (e.g., motor mechanism 150 and mechanical link 155).

According to embodiments, the control system 210 can control variousaspects of the operations of the vehicle lift 250. For instance, thecontrol system 210 can receive and process user requests 299 to storeand retrieve their vehicles on the vehicle lift 250. In doing so, thecontrol system 210 can perform various functions such as one or more of:communicating with user devices 295 operated by users 290 to receiveuser requests 299, verifying the users 290, communicating with a serviceplatform 270 to retrieve additional information regarding the users 290,determining an optimal sequence for moving the plurality of platformsfor a given set of user requests, and/or controlling the movement of theplatforms on the vehicle lift 250 in accordance with the determinedsequence. In certain implementations, the connected VLSS 200 may includea plurality of vehicle of various configurations all of which can becontrolled by the control system 210.

In the examples described herein, the control system 210 can include anetwork interface 225 for communicating with user devices 295 operatedby users 290 over one or more networks 280. The user devices 295 canexecute dedicated user application 296. The dedicated user application296 can enable a user 290 to submit a request 299 to store or retrievehis or her vehicle on the vehicle lift 250. The user device 295 cantransmit, via the user application 296, location data 297 and user ID298 to the control system 210 as part of the request 299 to retrieve orstore the user's vehicle. The location data 297 can be generated by alocation-aware resource of the user device 295 (e.g., GPS, GLONASS,Galileo, or BeiDou receiver) and can indicate a current location of theuser 290. The user ID 298 can be a unique identification number or tokenfor the user 290 across the cloud or network service managed by theservice platform 270.

In certain implementations, the control system 210 can also communicatewith a service platform 270 via the network interface 225 and the one ormore networks 280. The service platform 270 can run a cloud or networkservice for operating and managing a plurality of VLSS's such as theconnected VLSS 200. For instance, the cloud or network service canenable a uniform and consistent user access and experience across theplurality of VLSS's managed by the cloud or network service. In doingso, the service platform 270 can maintain a corresponding user profilefor each of a plurality of users 290. The service platform 270 can alsoprocess financial transactions and handle parking reservationsassociated with the users' use of the VLSS's.

According to embodiments, the control system 210 can include supervisorycontrol and data acquisition (SCDA) 215. The SCDA 215 can act as acentral hub or processor of the control system 210 to receive andprocess requests and other information. Among other functions, the SCDA215 can generate a control signal 216 to control the movement of theplatforms of the vehicle lift 250. As part of this function, the SCDA215 can also receive sensor data 256 from sensors 255 of the vehiclelift 250. Such sensors can include accelerometers attached to platformsof the vehicle lift 250 as well as other sensors. For instance, thecontrol signal 216 can be generated by the SCDA 215 based on the sensordata 256. In other respects, the SCDA 215 can receive user requests tostore or retrieve vehicles via the network interface 225 and processsuch requests.

To retrieve his or vehicle, the user 290 can transmit a request 299 forvehicle retrieval operations. The request 299 can include the user'slocation data 297 and a user ID 298 of the user 290. The user 290 caninteract with the user application 296 to transmit the request 299requesting vehicle retrieval operations. In some implementations, theuser device 295 can be configured to automatically transmit the request299 requesting vehicle retrieval operations. For instance, the userdevice 295 can be configured to automatically transmit the request 299based on the user device 295 being located within a certain distance ofthe connected VLSS 200 (e.g., based on the location data 297) or basedon the user device 295 being within communication range of the connectedVLSS 200 (e.g., within Bluetooth or Wi-Fi range, etc.). For example, therequest 299 can be automatically transmitted once the user device 295 isconnected to a particular Wi-Fi network or establishes Bluetoothconnection with the connected VLSS 200.

In response to receiving a user request 299 to retrieve the user'svehicle, the control system 210 can identify, based on the user ID 298,a platform on which the user's vehicle is stored from the plurality ofplatforms of the connected VLSS 200. For instance, the control system210 can include a database 220 that maintains storage records 221 thatassociate users and their vehicles with the platforms the vehicles arestored on. Thus, by querying the database 220 (e.g., using the user ID298), the SCDA 215 can receive a platform ID 223 that identifies theplatform on which the user's vehicle is stored. In some instances, theuser 290 may have two or more vehicles stored on the storage lift 250.In such situations, the request 299 can further specify a vehicle ID andthe SCDA 215 can further query the database 220 using the specifiedvehicle ID to identify the platform to be moved to a vehicular accessposition.

According to embodiments, the control system 210 can include a queueingengine 245 for determining and updating a sequence for moving theplatforms to fulfill user requests to store and retrieve vehicles. Thesequence can identify the order and positions in which platforms aremoved to fulfill pending user requests. In one aspect, the controlsystem 210 and the queueing engine 245 can determine and/or update thesequence based on the existing or current positions of the platformswithin the vehicle lift 250. For instance, a sequence determined inresponse to a vehicle retrieval request from user 290 for his or hervehicle can depend on where that vehicle is stored within the vehiclelift 250. The database 220 can store this information as part of thestorage records 221. In addition, the sequence can be determined and/orupdated based on information that can indicate when user will be readyto retrieve his or vehicle, including as a requested time indicated inthe retrieval request, user location, user profile information, and thelike. In some instances, no other user requests are pending and thequeueing engine 245 simply determines the optimal sequence of platformmovements to move the identified platform storing the user's vehicle toa vehicular access position. The queueing engine 245 can optimize thesequence based on fewest number of platform movements, quickestestimated time to retrieve the vehicle, minimize wait times for the usersubmitting requests, etc.

An example sequence can be described with respect to FIGS. 2B to 2D.FIGS. 2B to 2E illustrate front views of an exemplary vehicle lift 250being configured in accordance with a 3×2 Puzzle VLSS Configurationhaving five platforms (Platforms 1-5) for storing vehicles. The fiveplatforms can be moved into six possible positions within the vehiclelift 250: Positions A-F. Of the six possible positions, three (PositionsB, D, and F) are vehicular access positions because they are on the samelevel as the ground. FIG. 2B illustrates a view of the exemplary vehiclelift 250 prior to receiving a user request to retrieve vehicles. In FIG.2B, three vehicles are stored on the vehicle lift 250: Vehicle 1 onPlatform 1, Vehicle 2 on Platform 3, and Vehicle 3 on Platform 4. Inresponse to receiving a request 299 from a user device 295 for retrievalof the vehicle of user 290, the control system 210 can first determine,based on the user ID 298, that the vehicle of the user 290 (Vehicle 1)is stored on Platform 1. Subsequently, the control system 210 and/or thequeueing engine 245 can determine that, to retrieve Vehicle 1 (e.g.,move Platform 1 to a vehicular access position), the optimal sequenceis: (1) move Platform 4 to Position F, (2) move Platform 2 to PositionD, and (3) move Platform 1 to Position B. FIG. 2C illustrates thepositioning of the platforms within the vehicle lift 250 after thedetermined sequence of platform moves to retrieve the user 290's vehicle(Vehicle 1) has been completed. As can be seen, Vehicle 1 is now in avehicular access position (Position B), thus allowing the user 290 toretrieve Vehicle 1 from the vehicle lift 250. The optimal sequence canbe so determined because the sequence involves the least number ofplatform moves and is also estimated to be the fastest.

In some instances, one or more other requests to retrieve or storevehicles may be pending while the control system 210 receives userrequest 299. Or the request 299 can be received at substantially thesame time as another request from another user. In such instances, thecontrol system 210 and the queueing engine 245 can perform multi-variateoptimizations to determine an optimal sequence for the multiple userswho are requesting vehicle storage or retrieval operations. The sequencecan be determined and/or updated to minimize the cumulative wait time ofeach of the users who have submitted requests. In one aspect, thesequence can be determined based on respective locations of therequesting users. For instance, a user's vehicle retrieval request canbe de-prioritized (e.g., placed in the back of the sequence) based onthe user's data indicating that the user is located far away from thevehicle lift 250 (or the connected VLSS 200). In addition or as analternative, the control system 210 and/or queueing engine 245 canestimate a time of arrival at the vehicle lift 250 for each of the userswho submitted a vehicle retrieval request based on the users' respectivelocation data. The queueing engine 245 can then determine a sequence orupdate an existing sequence based on the estimated times of arrival ofthe users. In addition, the sequence can be determined based oncomparing the location data and/or ETA of two or more users.

In the above described example, a second request for vehicle retrievalfrom a second user can be received while the vehicle lift 250 isperforming the operations to move Vehicle 1 to Position B. In responseto the second request, the control system 210 can determine that thesecond user's vehicle (Vehicle 2) is stored on Platform 3. Thus, tofulfill both the first request (retrieval of Vehicle 1) and the secondrequest (retrieval of Vehicle 2), both Platforms 1 and 3 need to bemoved to one or more vehicular access positions. The control system 210can compare the location data of the first user (user 290) and thesecond user to determine that the first user is much closer to thevehicle lift 250 and thus likely to be ready to retrieve Vehicle 1 muchearlier than the second user is able to retrieve Vehicle 2. In responseto such a determination, the queueing engine 245 can determine to updatethe sequence such that Platform 1 is moved to Position B for the firstuser to retrieve Vehicle 1 (as illustrated in FIG. 2C) and after Vehicle1 is retrieved, Platform 3 is moved to Position D to allow Vehicle 2 tobe retrieved by the second user. Accordingly, the sequence is updated tobe: (1) move Platform 4 to Position F, (2) move Platform 2 to PositionD, (3) move Platform 1 to Position B (and wait for Vehicle 1 to move offPlatform 1), (4) move Platform 1 back to Position A, (5) move Platform 2to Position B, and (6) move Platform 3 to Position D. FIG. 2Dillustrates the positioning of the platforms within the vehicle lift 250after this updated sequence of platform moves has been completed. Giventhe information that the first user is much closer to the vehicle lift250 than the second user, this determined sequence can minimize the waittimes for both users.

On the other hand, the control system 210 determine, based on therespective location data of the first and second users, that the seconduser is likely to arrive at the vehicle lift 250 at approximately thesame time. In such a scenario, it may be undesirable to force the seconduser to wait for the first user to retrieve Vehicle 1 before Vehicle 2is ready for retrieval (as illustrated in FIGS. 2C and 2D). Thus, basedon this determination, the queueing engine 245 can determine to updatethe sequence to move both Vehicle 1 and Vehicle 2 to vehicular accesspositions before allowing either of the users to retrieve theirvehicles. For instance, the queueing engine 245 can update the sequenceto be: (1) move Platform 4 to Position F, (2) move Platform 2 toPosition D, (3) move Platform 1 to Position B, (4) move Platform 3 toPosition A, (5) move Platform 2 to Position C, (6) move Platform 1 toPosition D, and (7) move Platform 3 to Position B. FIG. 2E illustratesthe positioning of the platforms within the vehicle lift 250 after thisupdated sequence of platform moves has been completed. Compared with thesequence discussed above with respect to FIG. 2D, the first user mayhave to wait an additional amount of time before she or he can retrieveVehicle 1 and there are seven required platform moves compared with six.However, the cumulative wait time of both the first user and the seconduser is optimized because the second user does not have to wait for thefirst user to retrieve Vehicle 1 before Vehicle 2 can be moved intoplace for retrieval. Thus, in the given circumstances (e.g., the firstuser and the second user estimated to arrive at the vehicle lift 250 atapproximately the same time), this updated sequence can be more optimal.

Referring back to FIG. 2A, in certain implementations, the controlsystem 210 and queueing engine 245 can determine and/or update thesequence based on profile data 271 received from the service platform270. The profile data 271 can be data retrieved from a correspondinguser profile 276 maintained for the requesting user 290. For instance,the profile data 271 can indicate a preference for the user 290 toretrieve his or her vehicle at a preferred vehicular access position(e.g., a preferred entry/exit in a Tower Configuration VLSS). Based onthis information, the control system 210 and queueing engine 245 candetermine the sequence such that the vehicle of user 290 is moved to thepreferred vehicular access position in response to a vehicle retrievalrequest from the user 290. The profile data 271 can further indicateparameters gathered from past usage of VLSS's managed by the serviceplatform 270 by the user 290. As an example, the profile data 271 canindicate that the user 290 typically arrives earlier than requestedvehicle retrieval times indicated in the user's requests. Based on thisinformation and in response to a request 299 from the user 290, thecontrol system 210 and queueing engine 245 can update the sequence suchthat the vehicle of the user 290 can be ready for retrieval before arequested time indicated in the user's request 299.

It is contemplated that the control system 210 and queueing engine 245can determine sequences of platform movements for other configurationsof the vehicle lift 250 or connected VLSS 200. For example, the controlsystem 210 and queueing engine 245 can determine sequences for othertypes of Puzzle Configurations, such as a 4×3 Puzzle Configuration or a6×4 Puzzle Configuration. Similarly, the control system 210 and queueingengine 245 can determine sequences for a Tower Configuration VLSS. Asdescribed with respect to FIGS. 2B to 2E, these sequences can bedetermined and updated in response to user requests and based, at leastin part, on one or more of: the current positions of the platformswithin the vehicle lift 250, location data of each of the userssubmitting vehicle retrieval requests, ETA to the vehicle lift 250 ofeach of the users submitting vehicle retrieval requests, user profileinformation, and the like. In addition, for certain configurations likethe Tower Configuration, there can be multiple sequences determined forthe vehicle lift 250. For instance, a Tower Configuration can have twoor more vehicular access positions and the platforms may be movedindependently between to and from these vehicular access positions. Insuch instances, the control system 210 and the queueing engine 245 maymanage two or more independent sequences for moving the platforms to andfrom these vehicular access positions to complete vehicle retrieval andstorage requests from users.

In addition, the control system 210 and queueing engine 245 candetermine to move the platforms of vehicle lift 250 based on scheduleduser requests or in anticipation of user requests. For instance, thecontrol system 210 can receive a request 299 indicating a request toretrieve the vehicle of the user 290 in two hours. In response, thecontrol system 210 and queueing engine 245 can optimize the sequencesuch that during downtimes in the following two hours (e.g., duringtimes when there would otherwise be no platform movements), the platformstoring the vehicle of user 290 can be moved towards or closer to avehicular access position such that the vehicle can be quickly retrievedfor the user 290 in two hours' time. As another example, the controlsystem 210 and queueing engine 245 can anticipate a future user requestbased, for example, on profile data 271 indicating that the user 290typically retrieves her or his vehicle at 5 P.M. on weekdays. Inresponse, the control system 210 and queueing engine 245 can determineto move the platform storing the vehicle of user 290 towards or closerto a vehicular access position at 4:30 P.M. such that the vehicle can beeasily retrieved for the user 290 at 5:00 P.M., when the user 290typically retrieves the vehicle.

Furthermore, the control system 210 and the queueing engine 245 candetermine and/or update the sequence in response to receiving therequest 299 from the user 290 requesting for vehicle storage operations.Vehicle storage requests can be treated similarly to vehicle retrievalrequests in that an existing sequence of platform movements can beupdated to accommodate for a received vehicle storage request. Inresponse to a request 299 to store a vehicle, the queueing engine 245can determine a position within the vehicle lift 250 to store thevehicle and based on that optimal position, determine a sequence ofplatform movements (or update an existing sequence) such that theplatform storing the vehicle of the user 290 is moved into thedetermined position. According to one aspect, in response to a vehiclestorage request, the control system 210 and the queueing engine 245 candetermine the optimal position for the vehicle of the user 290 based onprofile data 271. The profile data 271 may indicate a preferred positionwithin the vehicle lift 250 to store the user's vehicle. In addition,the profile data 271 can include usage history information. As anexample, the profile data 271 can indicate that the user typicallystores his or her vehicle from 8 A.M. to 5 P.M. on weekdays (e.g.,parking at the user's workplace). In response, the control system 210and queueing engine 245 can determine an optimal position to store theuser's vehicle given this information. For instance, given that the user290 typically stores his or her vehicle typically during business hours,the queueing engine 245 can determine to move the platform storing theuser's vehicle to a position farther away from the vehicular accesspositions since the vehicle does not need to be accessed for many hours.In another respect, the request 299 for vehicle storage operations canfurther indicate an expected time of vehicle retrieval, which can beused to determine the position to which the platform storing the user'svehicle will be moved. As an example, the user 290 can indicate in therequest 299 for vehicle storage operations that she or he will retrievethe vehicle within an hour of storing it (e.g., a short trip to thestores). In response, the control system 210 and the queueing engine 245can determine to move the platform storing the vehicle of the user 290to a position close to a vehicular access position because the vehicleis expected to be retrieved soon. Such optimizations performed by thecontrol system 210 and the queueing engine 245 in storing vehicles canreduce platform movements and wait times for users of the vehicle lift250.

In addition, the control system 210 and the queueing engine 245 candetermine the sequence of platform movements in response to a request299 (e.g., for retrieval or for storage) based, at least in part, onmaintenance records 222 maintained in the database 220. For example, themaintenance records 222 can indicate malfunctions with moving platformsinto a particular position within the vehicle lift 250. The controlsystem 210 may have detected such malfunctions during previousoperations of the vehicle lift 250 or an administrator may have enteredthe information regarding the malfunction into the database 220. Basedon this maintenance information, in response a request 299, the controlsystem 210 and the queueing engine 245 can determine a sequence thatdoes not involve moving any platforms in into the particular positionexperiencing malfunctions. As another example, a given platform may haveissues preventing vehicles from safely getting on and/or off theplatform. Based on this maintenance information, the control system 210and the queueing engine 245 can operate in response to a request 299 forvehicle storage operations such that the problematic platform is notidentified for vehicle storage. In addition, the control system 210 cantransmit information regarding detected or identified malfunctions orproblems to the service platform 270 to enable the service platform 270to maintain up-to-date availability information in view of themalfunctions or problems. Among other benefits, this allows theconnected VLSS 200 to continue operating even when mechanical or otherproblems are detected or identified.

According to one implementation, some of the platforms of the vehiclelift 250 can include specialized equipment such as electric vehiclecharging ports. Thus, the SCDA 215 and the queueing engine 245 candetermine, in response to a request 299 to store a vehicle, to move oneof the platforms that include the specialize equipment to a vehicularaccess position such that the requesting user may access the specializedequipment. For instance, the request 299 or the profile data 271 of theuser may indicate that the vehicle being stored by the user 290 is anelectric vehicle. In response to such a request 299, the SCDA 215 andthe queueing engine 245 can identify an available platform that includescompatible electric vehicle supply equipment (EVSE) for charging theuser's vehicle. The SCDA 215 and the queueing engine 245 can cause theidentified platform to be moved to a vehicular access position such thatthe user's vehicle can be stored on the identified platform. In thismanner, the EVSE of the identified platform can be used to charge theon-board batteries of the user's electric vehicle while the vehicle isbeing stored in the vehicle lift 250.

According to embodiments, the SCDA 215 can further generate a message218 to be transmitted to the user device 295 via the network interface225 and the one or more networks 280. The message 218 can be transmittedafter a requested vehicle storage operation has been completed. Themessage can inform the user 290 that the user's vehicle has been stored.In response, the user application 296 can prompt a user input of a timeto retrieve the vehicle such that a vehicle storage request can bescheduled. In addition, the message 218 can be transmitted in responseto a vehicle retrieval request. In this instance, the message 218 caninform the user 290 of an estimated time the vehicle will be ready forretrieval. In certain examples, the message 218 can further inform theuser 290 of the vehicular access position the vehicle will be placedafter the retrieval operation is complete. For instance, for a TowerConfiguration VLSS having a plurality of vehicular access positionslocated at different access points of a building structure, the message218 can inform the user at which access point to pick up her or hisvehicle.

In certain implementations, the control system can include an AVinterface 230 for interfacing with autonomous vehicles (AVs). The SCDA215 can generate AV instructions 217 for transmission to an AV 285. TheAV instructions 217 can be transmitted via the one or more networks 280or can be transmitted via a local network (e.g., Wi-Fi or Bluetooth) ora dedicated wireless communication channel. The AV instructions 217 cancause the AV 285 to enter and exit the vehicle lift 250 (e.g., pull intoor pull out of a vehicular access position). Thus, as part of thevehicle storage and/or retrieval operations, the control system 210 candirect the AV 285 to autonomously drive itself onto or off the vehiclelift 250.

In various aspects, the vehicle lift 250 can include one or more cameras260 which can transmit camera data 261 to the control system 210 via thelift interface 235. The camera data 261 can be routed to a machinevision module 240 which can perform image analysis on the receivedcamera data 261. The image analysis performed by the machine visionmodule 240 can be used to determine whether a vehicle is free ofoccupants (e.g., one or more persons or pets) prior to moving thevehicle to a storage position within the vehicle lift 250. For instance,the one or more cameras 260 can be positioned to capture images orvideos through the windshield of the vehicle to allow the machine visionmodule 240 to determine if any occupants remain in the vehicle. Themachine vision module 240 can further determine if any persons orobjects are on the platform. In response to determining that at leastone occupant remains in the vehicle or if a person or an object isplaced on the platform, the machine vision module 240 can generate asafety signal 241 to the SCDA 215 to enable the SCDA 215 to stop thevehicle lift 250 from moving the platform (e.g., via the control signal216). In certain implementations, the machine vision module 240 can alsobe configured to perform facial recognition to determine the identity ofthe user 290. In this manner, the user 290 can store and/or retrieve heror his vehicle by simply walking up to the vehicle lift 250. In doingso, the machine vision module 240 can identify the user andautomatically process an appropriate request (e.g., store or retrieve)for the user based on the user's identity.

FIG. 3 is a block figure diagram illustrating a network system 300implementing a cloud or network service for managing a plurality ofVLSS's 350, 355, and 360, in accordance with examples described herein.In the below discussion of FIG. 3, reference may be made to features andexamples shown and described with respect to FIGS. 1 and 2A. Forinstance, network system 300 can be an embodiment of the serviceplatform 270 shown and described with respect to FIG. 2A. In addition,the VLSS 350, 355, and 360 can be embodiments of the VLSS 200 shown anddescribed with respect to FIG. 2A.

Referring to FIG. 3, the network system 300 can communicate with theplurality of VLSS's 350, 355, and 360 via a network interface 315 overone or more networks 380 in order to manage the plurality of VLSS's 350,355, and 360. In one respect, the network system 300 can manage parkingassignments across the plurality of VLSS's 350, 355, and 360. Forinstance, the network system 300 can determine, in response to aparticular user's request for vehicle storage operations, in which ofthe plurality of VLSS's 350, 355, and 360 the user's vehicle is to bestored. In doing so, the network system 300 can maintaindynamically-updated availability information for each of the pluralityof VLSS's 350, 355, and 360.

According to embodiments, the network system 300 can also communicatewith a user device 395 that executes a user application 396 to receive arequest 397. The request 397 can correspond to a request for vehiclestorage operations from a user 390 or to a request for vehicle retrievaloperations. The request 397 can include location data generated by oneor more geo-aware resource of the user device 395. The request 397 canfurther include identification information (e.g., a unique username oruser identification code) of the user 390. In certain implementations,the request 397 for vehicle storage operations can also indicate anrequested duration of the time the user expects to store his or hervehicle.

In response to receiving a request 397 requesting vehicle storageoperations, an assignment engine 330 of the network system 300 candetermine a dynamic parking assignment 331. The dynamic parkingassignment 331 can indicate at which of the plurality of VLSS's 350,355, and 360 the user's vehicle is to be stored. In certainimplementations, the dynamic parking assignment 331 can further indicatea position or section within a particular VLSS the user's vehicle is tobe stored. The dynamic parking assignment 331 can be determined based onthe availability information maintained by the network system 300 in aservice database 340 (e.g., availability records 342). The dynamicparking assignment 331 can also be determined based on the user'slocation data transmitted as part of the request 397. For instance, theassignment engine 330 can determine the dynamic parking assignment 331such that the identified VLSS is the closest one to the user 390 thathas availability for the requested duration of time. After the dynamicparking assignment 316 has been determined, it can be transmitted to therelevant VLSS. In addition, the network interface 315 can generate andtransmit, to the user device 395, a confirmation message 316. Theconfirmation message 316 can indicate the location of the assigned VLSSfor the user 390's request 397. The confirmation message 316 can furtherinclude an indication of the estimated cost to the user 390 for parkingthe vehicle for the requested duration of time at the assigned VLSS.

From the user 390's point of view, the request 397 for vehicle storageoperations can be performed automatically by the user device 395. Forinstance, the user 390 can, via the user application 396 or via athird-party mapping application, indicate a destination location such asa point of interest (e.g., a restaurant or a shop). In response, theuser device 395 can be configured to automatically transmit the request397 for vehicle storage operations. The request 397 can indicate thedestination location or the point of interest as the location associatedwith the request 397. The request 397 can also be transmitted ahead ofthe user 390 arriving at the destination location and can indicate anestimated time of arrival at the destination location. Thus, the userdevice 395 can be configured to seamlessly and automatically request aparking assignment on behalf of the user 390 as the user 390 travels tothe destination location. The network system 300 can then determine adynamic parking assignment 331 for the user 390 and transmit therelevant information (e.g., location of the assigned VLSS) via theconfirmation message 316. In response to receiving the confirmationmessage 316, the user application 396 and/or the third-party mappingsoftware can be automatically updated to guide (e.g., via turn-by-turnnavigation guidance) the user 390 to the location of the assigned VLSS.

In certain implementations, the availability records 342 maintained bythe network system in service database 340 can include informationregarding reserved parking assignments. For instance, a certain user maybe permanently assigned to park his or her vehicle(s) at a particularone of the plurality of VLSS's managed by the network system 300. Theparticular VLSS may be a VLSS located at or near the certain user'splace of residence or work. The reserved parking assignments can beassociated with time periods in which parking for the certain user'svehicle(s) is guaranteed at the particular VLSS (e.g., 8 A.M. to 6 P.M.on weekdays). Outside of the indicated time periods, the assignmentengine 330 can assign a space that is otherwise reserved for the certainuser to other users requesting vehicle storage operations. Thus, thedetermination of a dynamic parking assignment 331 can be based onreserved parking assignments indicated in the availability records 342.In this manner, the network system 300 can dynamically manage theinventory of available parking spaces in the plurality of VLSS's 350,355, and 360 to best suit the demand conditions.

According to embodiments, the service database 340 can also store userprofiles 341. Each user of the cloud service managed by the networksystem 300 can have a corresponding user profile 341. A user profile 341can include information such as name, address, contact information,method of payment, usage history information, and any permanent parkingreservations. In various aspects, the dynamic parking assignment 331 canbe determined based on profile data 343 retrieved from the user 390'suser profile 341. For instance, the profile data 343 can indicate thatthe user has a reserved position at one of the VLSS's managed by thenetwork system 300.

In various aspects, the network system 300 can include an admin console320 for receiving administrator input 376 from an administrator device375 operated by an administrator 370 of the network system 300. Theadministrator 370 can oversee various aspects of the cloud or networkservice run by the network system 300 for managing the plurality ofVLSS's. For example, the administrator input 376 can modify userprofiles 341 and assign reserved parking assignments at the VLSS's tospecific users. The modifications 377 made by the administrator 370 canbe saved to the service database 340. In addition, the network system300 can include payment processing 335 for processing payments on behalfof users. The payment processing 335 can retrieve payment processinginformation 344 from the service database 340 (e.g., using billinginformation in the user profiles 341). The payment processing 335 cangenerate payment processing data 336 for transmission to one or morefinancial institutions. In certain implementations, the platforms of theVLSS's 350, 355, or 360 can include electric vehicle supply equipment(EVSE) for charging electric vehicles. For a user 390 charging his orher electrical vehicle at a VLSS managed by the network system 300, thenetwork system 300 can maintain a record of amounts of electricity(e.g., in terms of kilowatt hours) consumed by user 390's vehicle. Thus,the payment processing 335 can also process a payment for the user 390'sconsumption of electricity in charging his or her electric vehicle atthe VLSS.

Methodologies

FIG. 4 is a flow chart describing an example method of operating anexample VLSS, as shown and described herein. In the below discussion ofFIG. 4, reference may be made to features and examples shown anddescribed with respect to 1. For instance, the exemplary methodillustrated in FIG. 4 and described below can be performed by the VLSS100 of FIG. 1.

Referring to FIG. 4, the VLSS 100 can receive user input (410). Theinput can be received via a user terminal of the VLSS 100 or can bereceived via a mobile computing device operated by the user. The userinput can specify a request for a vehicle storage operation or a vehicleretrieval operation. In response to the user input, the VLSS 100 candetermine to move a given platform of the VLSS 100 from its initialposition to a desired position (415). This determination can be based ona sequence of platform moves determined by the VLSS 100 in response tothe received user input. A plurality of platforms can be moved tovarious positions such that the user's request can be fulfilled. Anexemplary sequence for platform moves in response to a user request areshown and described with respected to FIGS. 2B to 2E. As part of thesequence of platform moves determined by the VLSS 100 in response to theuser request, the given platform can be determined to be moved from itsinitial position to the desired position. In other words, the givenplatform can be moved to the desired position as part of the determinedsequence of platform moves to fulfill the user's request.

According to embodiments, the control system 145 of the VLSS 100 cangenerate control signal 146 to cause the motor mechanism 150 to move thegiven platform from its initial position to the desired position (420).The control system 145 can then begin monitoring the output of theaccelerometer 135 attached to the given platform (425). The controlsystem 145 can monitor for a pitch rotation of the platform (426), aroll rotation of the platform (427), and an impact experienced by theplatform as it moves from its initial position to its desired position(428). The output of the accelerometer 135 can also be monitored for ayaw rotation of the platform.

The control system 145 can determine, based on the accelerometer output,whether a safety event has occurred (430). A safety event can bedetermined to have occurred if the pitch rotation of the platformexceeds a pitch threshold, if the roll rotation of the platform exceedsa roll rotation, or if the yaw rotation of the platform exceeds a yawthreshold. In addition, a safety event can be determined to haveoccurred if an impact is detected by the accelerometer prior to theplatform having reached the desired position.

If safety event has been detected, the control system 145 can generate acontrol signal to cause the motor mechanism to halt operating in itsnormal mode of operation in moving the given platform to the desiredposition (435). In addition or as an alternative, the control system 145can generate a safety signal to the motor mechanism 150 to cause themotor mechanism 150 to cease operating in its normal mode of operationin moving the platform to the desired position.

In certain implementations, the control system 145 can characterize thedetected safety event or determine an event type for the detected safetyevent based on the data from the accelerometer 135. Based on thecharacterization of the safety event or the determined event type, thecontrol system 145 can cause the motor mechanism to perform a variety ofsafety functions to alleviate or resolve the safety event. For instance,if the detected safety event is determined to correspond to the givenplatform impacting an external object (e.g., an open car door) whilebeing moved from its initial position to the desired position, thecontrol system 145 can cause the motor mechanism to operate in a safetymode to bring the given platform back to its initial position (440).

If no safety event is detected and the given platform has been movedinto the desired position, the VLSS 100 can proceed to moving the nextplatform specified in the sequence of platform moves to fulfill the userrequest (450).

FIG. 5 is a flow chart illustrating an example method of performing avehicle retrieval operation, as shown and described herein. In the belowdiscussion of FIG. 5, reference may be made to features and examplesshown and described with respect to FIGS. 2A to 2E. For instance, theexample method of performing vehicle retrieval operation 500 can beperformed by the connected VLSS 200 of FIG. 2A.

Referring to FIG. 5, the connected VLSS 200 can receive a user requestfor vehicle retrieval (510). The user request can include identificationinformation of the user and the user's location data. The user requestfor vehicle retrieval can be received from a user console located at ornear the connected VLSS 200 (511). The user request for vehicleretrieval can also be received via one or more networks from a computingdevice operated by the user (512).

In response to the user request for vehicle retrieval, the connectedVLSS 200 can query a service platform for user profile information ofthe requesting user (515). The connected VLSS 200 can further identifythe platform storing the vehicle associated with the requesting user(520). In addition, the connected VLSS 200 can estimate an ETA of therequesting user at the vehicle lift 250 based on the user's locationdata (525).

According to embodiments, the connected VLSS 200 can determine asequence for moving the platforms of the vehicle lift 250 in order tofulfill the user's request for vehicle retrieval (530). If the connectedVLSS 200 has other pending user requests for storing or retrievingvehicles, there can be an existing sequence for moving the platforms ofthe vehicle lift 250. Thus, in response to the requesting user'srequest, the existing sequence can be updated to include operations tofulfill the requesting user's request. The sequence can be determined orupdated based on the current positions of the platforms in the vehiclelift 250 (531), including the identified platform that stores therequesting user's vehicle. The sequence can also be determined based onthe user's ETA (532). For instance, the requesting user's ETA can becompared against ETAs of other users who have submitted requests. If therequesting user is estimated to arrive at the vehicle lift 250 earlierthan the other users, the requesting user's request for vehicleretrieval can be prioritized to optimize and reduce wait time. On theother hand, if the requesting user is estimated to arrive at the vehiclelift 250 later than other users, the other users' requests can beprioritized over the requesting user's request. The sequence can also bedetermined or updated based on information contained in the user profile(533). For instance, the user profile can indicate a preferred vehicularaccess position for retrieving the requesting user's vehicle.

After the sequence is determined or updated, the control system of theVLSS 200 can generate control signal(s) to cause the motor mechanisms ofthe VLSS 200 to move the platforms of the VLSS 200 in accordance withthe determined or updated sequence (535). In addition, the VLSS 200 cantransmit, to the requesting user's computing device, an estimated timeat which the requesting user's vehicle will be ready for pickup by therequesting user (540). In addition, if the VLSS 200 has multiplevehicular access positions, the VLSS 200 can further transmit to therequesting user's computing device information regarding the vehicularaccess position (e.g., an exit number, a stall number, etc.) at whichthe requesting user's vehicle will be placed for pickup by therequesting user.

FIG. 6 is a flow chart illustrating an example method of performing avehicle storage operation, as shown and described herein. In the belowdiscussion of FIG. 6, reference may be made to features and examplesshown and described with respect to FIGS. 2A to 2E. For instance, theexample method of performing vehicle storage operation 600 can beperformed by the connected VLSS 200 of FIG. 2A.

Referring to FIG. 6, the connected VLSS 200 can receive a user requestfor vehicle storage (610). The user request can include identificationinformation of the user and the user's location data. The user requestfor vehicle storage can be received from a user console located at ornear the connected VLSS 200 (611). The user request for vehicle storagecan also be received via one or more networks from a computing deviceoperated by the user (612).

In response to the user request for vehicle storage, the connected VLSS200 can query a service platform for user profile information of therequesting user (615). Based on the user profile information, the VLSS200 can determine whether the requesting user has a reserved storageposition (620). If the user has a reserved position within the vehiclelift 250, the VLSS 200 can determine a sequence of platform moves tomove the vehicle to the reserved position (630). However, if the userdoes not have a reserved position, the VLSS 200 can determine a storageposition for the user's vehicle (625). The storage position can bedetermined based on a time duration requested as part of the user'srequest for vehicle storage. For instance, if the requested timeduration is short (e.g., less than an hour), the VLSS 200 can determineto move the user's vehicle to a position close to a vehicular accessposition. On the other hand, if the requested time duration is long, theVLSS 200 can determine to move the vehicle to a storage position that isfurther away from the vehicular access positions of the VLSS 200 suchthat other vehicles that will be stored in the VLSS 200 for shorterperiods of time can be placed near the vehicular access positions forquick retrieval. In addition, based on the determined position for theuser's vehicle, the VLSS 200 can determine or update a sequence ofplatform movements to move the vehicle into the determined storageposition (630). After the sequence is determined or updated, the controlsystem of the VLSS 200 can generate control signal(s) to cause the motormechanisms of the VLSS 200 to move the platforms of the VLSS 200 inaccordance with the determined or updated sequence (635).

Hardware Diagrams

FIG. 7 is a block diagram illustrating an example user device executingand operating a designated user application for communicating with acloud or network service and/or with a connected VLSS, according toexamples described herein. In many implementations, the user device 700can comprise a mobile computing device, such as a smartphone, tabletcomputer, laptop computer, VR or AR headset device, and the like. Assuch, the user device 700 can include typical telephony features such asa microphone 745, a camera 750, and a communication interface 710 tocommunicate with external entities using any number of wirelesscommunication protocols. In certain aspects, the user device 700 canstore a designated application (e.g., a user app 732) in a local memory730. In variations, the memory 730 can store additional applicationsexecutable by one or more processors 740 of the user device 700,enabling access and interaction with one or more host servers over oneor more networks 780.

In response to a user input 718, the user app 732 can be executed by aprocessor 740, which can cause an app interface 742 to be generated on adisplay screen 720 of the user device 700. The app interface 742 canenable the user to, for example, enter a request for vehicle storage ora request for vehicle retrieval. In various implementations, the appinterface 742 can further enable the user to enter or select one or morelocations related to the request (e.g., by entering an address,performing a search, or selecting on an interactive map). Furthermore,the app interface 742 can display dynamically information relating tothe request, such as confirmation messages, estimated times ofcompletion, and other information. The user can generate a request 767via user inputs 718 provided on the app interface 742.

As provided herein, the user application 732 can further enable acommunication link with a network system 790 over the network 780, suchas the network system 300 as shown and described with respect to FIG. 3.The processor 740 can generate user interface features 728 (e.g., map,request status, etc.) using content data 726 received from the networksystem 790 over network 780. Furthermore, as discussed herein, the userapplication 732 can enable the network system 790 to cause the generateduser interface 728 to be displayed on the application interface 742.

The processor 740 can transmit the requests 767 via a communicationsinterface 710 to the backend network system 790 over a network 780. Inresponse, the user device 700 can receive a confirmation 769 from thenetwork system 790. In various examples, the user device 700 can furtherinclude a GPS module 760, which can provide location data 762 indicatingthe current location of the requesting user to the network system 790.

FIG. 8 is a block diagram that illustrates a computer system upon whichexamples described herein may be implemented. A computer system 800 canbe implemented on, for example, a server or combination of servers. Forexample, the computer system 800 may be implemented as part of a networkservice managing connected VLSS's. In the context of FIG. 3, the networksystem 300 may be implemented using a computer system 800 such asdescribed by FIG. 8. The network system 300 may also be implementedusing a combination of multiple computer systems as described inconnection with FIG. 8.

In one implementation, the computer system 800 includes processingresources 810, a main memory 820, a read-only memory (ROM) 830, astorage device 840, and a communication interface 850. The computersystem 800 includes at least one processor 810 for processinginformation stored in the main memory 820, such as provided by a randomaccess memory (RAM) or other dynamic storage device, for storinginformation and instructions which are executable by the processor 810.The main memory 820 also may be used for storing temporary variables orother intermediate information during execution of instructions to beexecuted by the processor 810. The computer system 800 may also includethe ROM 830 or other static storage device for storing staticinformation and instructions for the processor 810. A storage device840, such as a magnetic disk or optical disk, is provided for storinginformation and instructions.

The communication interface 850 enables the computer system 800 tocommunicate with one or more networks 880 (e.g., cellular network)through use of the network link (wireless or wired). Using the networklink, the computer system 800 can communicate with one or more computingdevices, one or more servers, and/or one or more self-driving vehicles.In accordance with examples, the computer system 800 receives requests882 from computing devices of individual users. The executableinstructions stored in the memory 830 can include assignmentinstructions 822, which the processor 810 executes to determine dynamicparking assignments in response to requests for vehicle storage receivedfrom users. In doing so, the computer system 800 can receive locationdata of the user to determine the dynamic assignment 851 in response tothe user request 882. The processor 810 is configured with softwareand/or other logic to perform one or more processes, steps and otherfunctions described with implementations, such as described by FIGS.1-7, and elsewhere in the present application.

Examples described herein are related to the use of the computer system800 for implementing the techniques described herein. According to oneexample, those techniques are performed by the computer system 800 inresponse to the processor 810 executing one or more sequences of one ormore instructions contained in the main memory 820. Such instructionsmay be read into the main memory 820 from another machine-readablemedium, such as the storage device 840. Execution of the sequences ofinstructions contained in the main memory 820 causes the processor 810to perform the process steps described herein. In alternativeimplementations, hard-wired circuitry may be used in place of or incombination with software instructions to implement examples describedherein. Thus, the examples described are not limited to any specificcombination of hardware circuitry and software.

It is contemplated for examples described herein to extend to individualelements and concepts described herein, independently of other concepts,ideas or systems, as well as for examples to include combinations ofelements recited anywhere in this application. Although examples aredescribed in detail herein with reference to the accompanying drawings,it is to be understood that the concepts are not limited to thoseprecise examples. As such, many modifications and variations will beapparent to practitioners skilled in this art. Accordingly, it isintended that the scope of the concepts be defined by the followingclaims and their equivalents. Furthermore, it is contemplated that aparticular feature described either individually or as part of anexample can be combined with other individually described features, orparts of other examples, even if the other features and examples make nomentioned of the particular feature. Thus, the absence of describingcombinations should not preclude claiming rights to such combinations.

What is claimed is:
 1. A vehicle lift and storage system, comprising: aplurality of platforms for supporting motor vehicles, each of theplatforms being movable between a plurality of storage positions and oneor more vehicular access positions, the one or more vehicular accesspositions allowing for vehicular access to the vehicle lift and storagesystem; one or more moving mechanisms operatively connected to theplurality of platforms to move the platforms between the plurality ofstorage positions and the one or more vehicular access positions; acontrol system for controlling the vehicle lift and storage system, thecontrol system including a network interface for communicating over oneor more networks and being configured to: receive user data associatedwith a user of the vehicle lift and storage system, the user datacomprising location information of the user and identificationinformation of the user; based on the identification information of theuser, identify, among the plurality of platforms, a platform on which avehicle associated with the user is located; and based on a position ofthe identified platform and the location information of the user, updatea sequence for moving the plurality of platforms to include steps formoving the identified platform to one of the one or more vehicularaccess positions.